Автоматизация в продуктовых командах: как наладить поставку ценности в краткие сроки и без потерь

Как устроена работа продуктовой команды

Работа продуктовой команды состоит из множества взаимосвязанных процессов. Рамочным процессом является так называемый Value Stream Map (VSM), описывающий основные этапы по проектированию, разработке и внедрению нового функционала. Value Stream Map (VSM) — это инструмент визуализации потока создания ценности. Поставка, создание ценности - это последовательность всех операций, которые осуществляются с продуктом от идеи, начала проектирования и оформления концепции до доставки в готовом виде продукта клиенту.

VSM включает материальные и интеллектуальные потоки ресурсов, а также время.

Value Stream Map 

Параллельно с Value Stream Map внутри команды непрерывно идет работа над подготовкой и выпуском очередного дистрибутива ПО, включающая в себя такие этапы, как разработка, code review, ручное тестирование, e2e-тесты, демо, регресс и, наконец, деплой на прод:

Процесс подготовки дистрибутива ПО, идущий параллельно с Value Stream Map

У данного процесса есть пара особенностей. Первая особенность заключается в том, что большая часть его шагов автоматизирована с помощью пайплайнов. Пайплайн (pipeline) — это последовательность действий или процессов, которые выполняются для достижения заданной цели. Он состоит из этапов, на каждом из которых выполняется определенная задача или набор задач. Пайплайны используют в программировании, обработке данных, машинном обучении, сетевой инфраструктуре и других областях IT. Каждый пайплайн, по сути, является отдельным процессом, порой весьма сложным:

Структура пайплайна

Пайплайны связаны между собой. Завершение одного зачастую является триггером к запуску следующего, образуя таким образом длинные цепочки.

Вторая особенность в том, что подготовка дистрибутива содержит множество обратных петель. Если что-то где-то пошло не так, например, код не скомпилировался, не прошли unit-тесты, тестировщик нашел баг, «упал» раскат на стенд и т.п., мы возвращаемся в самое начало, вносим изменения в код и заново проходим большую часть шагов процесса. Как становится видно, работа продуктовой команды имеет комплексный характер, многоуровневую сложную структуру и включает в себя несколько параллельных процессов. Очевидно, что перед любой командой всегда стоит задача сокращения сроков поставки функционала заказчику. В контексте процессов это означает их постоянную оптимизацию. 

Оптимизация – как сократить потери

Если обратиться к ставшей уже классической концепции бережливого производства (Lean), созданной Тайити Оно, японским специалистом, который разработал производственную систему для компании Toyota в 1950-х годах, то можно получить следующий совет – ключом к совершенствованию производственных процессов является сокращение потерь. Рассмотрим один из видов таких потерь, а именно – потери времени. Разобьем потерю времени на три подтипа:

 1. Мы делаем руками то, что можно автоматизировать;

 2. Мы чего-то (кого-то) ждем;

3. Мы тратим время «впустую». 

1. «Делаем руками то, что можно автоматизировать» 

Ценность автоматизации наверняка понятна всем. Машинное время стоит значительно дешевле человеческого. Поэтому «все, что может быть автоматизировано, должно быть автоматизировано». Речь здесь идет не только о шагах сборки проекта и выкатки его на стенды. Стоит взглянуть на весь Value Stream Map и поискать в нем места, которые за нас может выполнить машина. Делимся примерами, как мы нашли такие места и автоматизировали:

1. Добавили в проекты пайплайн, который автоматически формирует и отправляет заказчику Release Notes после установки новой версии на prod. Это очевидно сокращает работу ПМ-ов, которые ранее собирали ноты вручную. 
2. В некоторых проектах есть пайплайн, маркирующий задачу в TFS тегом с именем стенда, на который задача была «раскатана». Здесь оптимизация достигается за счет сокращения коммуникаций внутри команды, ведь больше не нужно спрашивать коллег о том, где можно посмотреть результат. 
3. Реализовали скрипт, генерирующий и публикующий в TFS Wiki с описанием схемы базы данных (БД) проекта. Его ценность в постоянном наличии актуальной документации на БД, которую ранее приходилось писать вручную. 

2. «Мы чего-то (кого-то) ждем»

Взглянем на пайплайн, запускающийся при создании/обновлении Pull Request:

Пайплайн на Pull Request

Пайплайн состоит из четырех шагов. Если каждый шаг будет выполняться 5 минут, то общее время составит 20 минут. Эти 20 минут придется подождать, чтобы убедиться, что с кодом все хорошо и его можно отдавать на ревью. На практике, конечно, никто не сидит и не ждет. Обычно, разработчик переключается на другие задачи, чтобы не терять время. И тут может происходить другая интересная ситуация: переключившись на новую задачу, разработчик «забывает» про пайплайн и возвращается к нему не через 20 минут, а через пару часов. Таким образом, и сама задача уйдет на ревью значительно позже. «Потеря» очевидна.

С другой стороны, если бы пайплайн длился 1-2 минуты, можно было бы просто посидеть дождаться его завершения и сразу назначить ревьюера. Что можно с этим сделать: 

1. Ускорять отдельные шаги пайплайна. TFS предоставляет хорошую аналитику на этот счет. Можно посмотреть статистику продолжительности как всего пайплайна, так и отдельных его шагов и что-то с ними сделать. 
2. Запускать шаги «в параллель». Например, на пайплайне выше шаг с анализом кода на безопасность может быть запущен параллельно с остальными, что сократит время пайплайна с 20 до 15 минут. 

Отдельно стоит упомянуть об еще одной ситуации. Как известно, пайплайны запускаются на агентах TFS (каждый Job забирает себе одного агента). Число агентов ограничено и при одновременном запуске большого числа Job-ов часть из них может ждать, пока агенты освободятся. Естественно, время выполнения пайплайнов при этом увеличивается. Если такая ситуация возникает на проекте регулярно, можно попробовать следующие варианты:

1. Запросить под свой проект отдельный пул агентов, чтобы не делить их с другими проектами.
2. Если собственный пул уже есть, то можно разбить его на несколько частей и таким образом выделить несколько агентов на выполнение наиболее срочных пайплайнов. Например, в период подготовки релиза это может быть пайплайн с e2e-тестами.
3. Ускорять Job-ы. Чем меньше времени они выполняются, тем меньше вероятность попасть в ситуацию «пустого пула агентов». 

3. «Пустая» трата времени

Снова взглянем на пайплайн выше. Если после его запуска «упадет» третий шаг с unit-тестами, то время, потраченное на исполнение первых двух шагов, можно считать потерянным впустую. После исправления тестов их придется проходить повторно. Чтобы избегать подобных потерь, можно было бы сделать следующее:

1. Перед созданием/обновлением PR, разработчик может локально собрать проект и прогнать unit-тесты. Скорее всего, на его машине этот процесс займет меньше времени, чем в TFS, зато пайплайн с большей вероятностью отработает с первого раза.
2. Наиболее «рискованные» шаги пайплайна можно перенести ближе к его началу. Это сократит потери на прохождение промежуточных шагов.

О чем следует помнить команде при оптимизации времени?

Оптимизация времени позволяет командам сосредоточить все усилия на создании ценности для клиентов. Такой подход экономит ресурсы и деньги заказчика.

Как становится видно, оптимизация времени на каждом шаге - кропотливая аналитическая работа, во многом сопряженная с глубоким пониманием производственного процесса разработки. Для постоянного улучшения команда должна сокращать и устранять потери систематически. Это циклический процесс, поэтому недостаточно приложить усилия один раз. Принцип непрерывного совершенствования процесса должен быть заложен в основе оптимизации. 

Командам следует помнить, что помимо автоматизации необходимо отлаживать процесс поставки ценности практически вручную в зависимости от конкретных задач проекта. Например, где-то ускорять отдельные шаги пайплайна и Job-ы, а где-то запускать шаги «в параллель». 

Скорость и качество поставки ценности играют важную роль. В условиях высокой конкуренции и постоянных изменений рынка, автоматизация небольших шагов является ключом к грамотному и эффективному управлению временем. Автоматизация процессов и их непрерывная отладка вручную являются необходимым условием для достижения бизнес-целей заказчика и успешного развития IT-команд.

Узнать больше про наш опыт организации гибридных команд заказчика и подрядчика.